IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols

This memo describes the procedures and criteria for reviewing reliable multicast protocols within the Transport Area (TSV) of the IETF. Within today’s Internet, important applications exist for a reliable multicast service. Some examples that are driving reliable multicast technology are collaborative workspaces (such as whiteboard), data and software distribution, and (more speculatively) web caching protocols. Due to the nature of the technical issues, a single commonly accepted technical solution that solves all the demands for reliable multicast is likely to be infeasible [RMMinutes 1997]. A number of reliable multicast protocols have already been developed to solve a variety of problems for various types of applications. [Floyd97] describes one widely deployed example. How should these protocols be treated within the IETF and how should the IETF guide the development of reliable multicast in a direction beneficial for the general Internet? Mankin, et. al. Informational [Page 1] RFC 2357 Evaluating Reliable Multicast June 1998 The TSV Area Directors and their Directorate have outlined a set of review procedures that address these questions and set criteria and processes for the publication as RFCs of Internet-Drafts on reliable multicast transport protocols. 1.0 Background on IETF Processes and Procedures In the IETF, work in an area is directed and managed by the Area Directors (ADs), who have authority over the chartering of working groups (WGs). In addition, ADs review individually submitted (not by WGs) Internet-Drafts about work that is relevant to their areas prior to publication as RFCs (Experimental, Informational or, in rare cases, Standards Track). The review is done according to the guidelines set out in the Internet Standards Process, RFC 2026 [InetStdProc96]. The purpose of this document is to present the criteria that will be used by the TSV ADs in reviewing reliable multicast Internet-Drafts for any form of RFC publication. For I-Ds submitted for Standards Track publication, these criteria must be met or else the ADs will decline to support publication of the document, which suffices to prevent publication. For I-Ds submitted as Experimental or Informational, these criteria must be met or else, at a minimum, the Ads will recommend publishing the I-D with an IESG note prepended stating that the protocol fails to comply with these criteria.